feat(http-specs): add SSE protocol Spector scenarios - #11613

Previously missed (1) — in code that hasn't changed since the last review.

.chronus/changes/iscai-msft-add-sse-spector-scenarios-2026-7-10-14-23-58.md:7

• This entry is marked as changeKind: feature, and other feature entries in this repo typically include a short illustrative code block (often tsp) showing the new scenario/API surface (e.g. .chronus/changes/add-body-or-no-content-scenario-2026-8-14.md:9-16). Consider adding a small tsp snippet demonstrating one of the new SSE protocol scenarios so the changelog entry matches the established format for features.

Add SSE protocol coverage for event IDs, retry fields, and reconnection

Previously missed (1) — in code that hasn't changed since the last review.

packages/http-specs/specs/streaming/sse/mockapi.ts:216

• The reconnect mock relies on a closure-scoped reconnected flag to decide whether to enforce the last-event-id header. Because this handler instance is shared across the whole Spector server lifetime, the behavior becomes non-idempotent (e.g., reruns or concurrent requests can flip the flag and cause unexpected 400s). Prefer making the response selection deterministic from the request itself (e.g., treat presence of last-event-id as the reconnect call, validate it when present, otherwise return the initial response) so the mock is repeatable and robust.

      reconnected = true;
      return {
        pass: "initial",
        status: 200,
        body: {

Previously missed (3) — in code that hasn't changed since the last review.

packages/http-specs/specs/streaming/sse/main.tsp:272

• The reconnect scenario documentation says the first response closes after sending event-1, but the "Expected response body" section only shows the reconnect response (event-2). Since the mock sends an initial event-1 response before the reconnect, consider documenting both responses (initial + reconnect) or clearly labeling the snippet as "Expected response body on reconnect" to avoid ambiguity.

  @scenarioDoc("""
    An SSE stream that resumes after a reconnect. The first response closes after
    sending `event-1`. On reconnect, the client sends the most recently received
    event ID in the `Last-Event-ID` request header.

packages/http-specs/specs/streaming/sse/main.tsp:207

• There are whitespace-only lines inside the new @scenarioDoc blocks (e.g. the blank line after "not part of the typed event data."). These show up as trailing whitespace in diffs/linters and can cause git diff --check or format checks to fail. Remove the trailing spaces (make the line truly empty) or re-run the formatter on this file.

  @scenarioDoc("""
    An SSE event with an `id` field. The event ID is envelope metadata and is
    not part of the typed event data.
    
    Expected response body (content type `text/event-stream`):

packages/http-specs/spec-summary.md:5470

• This scenario description reads like a two-step flow (initial stream returns event-1, then reconnect returns event-2 with Last-Event-ID), but the "Expected response body" block only shows the reconnect response. Consider documenting both the initial and reconnect response bodies (or label this as the reconnect-only response) so readers understand what the client receives before it can send Last-Event-ID.

An SSE stream that resumes after a reconnect. The first response closes after
sending `event-1`. On reconnect, the client sends the most recently received
event ID in the `Last-Event-ID` request header.

Expected request header on reconnect:

Last-Event-ID: event-1

Expected response body (content type `text/event-stream`):